โ NomadNet 1.4.2 released
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Server interface that is gentler for mobile clients โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by Rama ยท 4mo ago ยท 763dcd6059324253
Page 1 of 2
[ 1 ] Next >
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-1
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Rama #1 โ
โ 763dcd6059324253 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Hi folks,
I've been trying hard to optimise battery performance of a mobile client (Columba
specifically, but I believe this is relevant to any mobile client), being mostly
concerned about performance on cellular data.
I tried a few things, but the most effective ones turned out to be:
1. Using an AP mode backbone interface when on cellular. (The docs mention LoRa transport
nodes as the featured use-case for AP mode, but I believe this is a valid use-case too.)
2. Increasing the tcp keepalive interval of the interface from 2 seconds to 5 minutes.
(This is what Conversations, the xmpp app, does and it shows stellar battery performance
without relying on push notifications.)
This way the cellular radio can sleep for longer periods resulting in much lower
discharge rate: ~7-10x more.
The TCP keepalive intervals are unfortunately hardcoded in the RNS interfaces, so I had
to roll a custom interface that basically extends BackboneInterface and does a couple of
overrides to make the keepalive options configurable.
My questions:
a. Does this setup make sense or am I missing some considerations?
b. Do you think there's merit in making keepalive options configurable upstream and
pleading with node ops to adjust configs? (or better update defaults upstream.)
All other performance battery optimizations seem futile: how well you manage wakelocks
doesn't matter, if you want to maintain persistent connection and that connection is
keeping the most power hungry component, the radio, awake.
Thanks in advance.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-2
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #2 โ
โ 8dd57a7382268096 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
One of the foundational problems here is that Columba turns on Transport by default
for every installation.
That means that every person's phone, tablet, and so on, is routing traffic, processing
announces and path requests, and generally using a lot of CPU cycles, bandwidth and
battery on things that:
โข Don't actually help the network
โข Doesn't benefit the user of the app
The reasons you're seeing improvements with AP mode is that it's limiting announce
transport processing significantly. But in reality, transport should have been off to
begin with.
I've advised the developer of Columba against this approach a couple of times (both on
privately, and on the Columba github repo), and specifically mentioned this would be bad
for battery life.
If you increase the keepalive interval to 5 minutes, would you like to wait 5 minutes
before RNS can detect that a TCP connection is broken, mark the interface as down, and
find another path?
In normal circumstances, sending a keepalive every few seconds will use practically no
energy. It's a few bytes only. The radio is kept awake anyway, there's not really any way
around that if you want to be connected to the network without Google's "services"
"helping" us out.
Some devices have really power-hungry WiFi/BT chipsets, some don't. Cheaper devices will
often have horrible power consumption when the radio is kept awake, but then again, I've
seen cheap phones with excellent chipsets that use very little power, even when kept
awake.
A good radio chipset will have neglible impact on battery life, even if awake, a bad one
will drain it very fast.
There's no magic bullet here, unfortunately. It varies wildly by device type and
model.
But really, most of it in this particular case is probably coming from:
โข Having transport turned on by default
โข Now routing announces, path-requests and traffic 24/7 from your pocket
This is not the intended default user configuration, and doing it like that is a broken
way of doing it.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-3
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #3 โ
โ 8dd57a7382268096 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Just as a reference, I'm using Sideband on my own device, have it running in the
background 24/7, connected to 5 different backbone remotes, plus auto-interface on WiFi,
plus RNode on standby on BT, so it connects as soon as the RNode is turned on, and I get
around 2-3 days of standby time.
It's not RNS eating your battery, it's Columba.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-4
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Torlando #4 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Hi Mark! I was worried after you didn't reply to my DMs last week, after you last asked
if I had disabled transport by default in Columba, that you might not have received my
messages. Quite relieved that this seems to have been the case!
Rest assured, transport has been disabled by default in Columba since
https://github.com/torlando-tech/columba/pull/777 (first released in v1.0.0-beta), where
you can see that someone actually complained that I disabled it by default (despite it
still being an option). While this doesn't change the setting for existing users,
v1.0.0-beta also installs as a separate app (new application ID) so effectively everyone
is a new user. I have also buried the option under an Advanced section at the bottom of
Settings, with a more verbose warning explaining the tradeoffs of enabling Transport on a
mobile device.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-5
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Rama #5 โ
โ 763dcd6059324253 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Hi Mark, thanks for replying and for your reference on battery performance.
โ One of the foundational problems here is that Columba turns on Transport by default
โ for every installation.
I believe this is no longer the case. I certainly didn't have it enabled by default when
I first installed columba a few weeks ago.
โ The reasons you're seeing improvements with AP mode is that it's limiting announce
โ transport processing significantly. But in reality, transport should have been off
โ to begin with.
Yes, I read the docs and that's why I chose AP mode. But again I don't have the transport
enabled.
My reference device is Pixel 7a. Two of them, and both are showing the same battery
performance. I've tested Sideband a while ago and Ratspeak recently, and the battery
performance numbers are similar to Columba. Could it be an issue with my carrier? I'll do
some more tests.
About your reference, would you be willing to share your device model? ๐
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-6
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Rama #6 โ
โ 763dcd6059324253 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
oh, forgot to respond to these points:
โ If you increase the keepalive interval to 5 minutes, would you like to wait 5
โ minutes before RNS can detect that a TCP connection is broken, mark the interface
โ as down, and find another path?
Yes, I wondered about this, and, just as one thought, it could be left to clients to be
adaptive here: if connection breaks, back off and cut the keepalive interval in half
accepting higher drain.
โ A good radio chipset will have neglible impact on battery life, even if awake, a
โ bad one will drain it very fast.
I wasn't aware of that. But then this begs a question of inclusivity. I'd assume cheap
devices with cheap radio chipsets are in the majority in the world.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-7
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #7 โ
โ 8dd57a7382268096 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
@Rama: If transport is not enabled, AP mode will have no effect. That setting only
affects code paths reachable when transport is enabled. So if it has an effect, that's a
pretty good sign that transport is actually enabled.
The latest release of Sideband (1.9.4) includes RNS 1.2.5, which has several small fixes
and improvements for weird edge-cases that were causing high battery drain; related
Android OS internal TCP socket buffering when the UI part of the app was sleeping, and
then some weird behavior on rmnet -type kernel interfaces (those are the
carrier-specific uplinks). The device I discovered these quirks on was actually a friends
Pixel 7a, so there's a chance that might help you out as well.
Take a look at the old power consumption / battery threads on the old github discussions,
there's some good info in there as well.
Also, as a side-note, until the RNS 1.2.5 release, the network was massively spammed
by broken and slopcoded LLM-ware, which spammed up to 100 path requests per second at
some points. This would have caused a lot of unnecessary processing overhead on end-user
devices.
I sat in front of my computer for more or less four days straight to implement reliable
control mechanisms for situations like this, and it is now effectively blocked and
managed by all nodes running RNS 1.2.5 and up, which should help quite a bit as well. But
if you're still connecting to an entrypoint sending you hundreds of path requests and
announces per second, it is going to drain the battery ;)
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-8
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Mark #8 โ
โ 8dd57a7382268096 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Hey Torlando
No, I didn't get those messages. Good to hear it's no longer enabled by default!
โ 0 โ 0 โค 1
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-9
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Torlando #9 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
Thanks for the confirmation Mark. Seems my latest build that I replied with has a bug in
the stamper path. Have it reproduced locally against Sideband, with stamp cost enabled
and drop invalid stamps enabled. Same behavior: got a delivery proof on Columba, no
message showed up on Sideband.
How embarrassing! :/ Oh well, I'll get it patched as soon as I can, and resend those
dropped messages to you once it's fixed.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-10
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Rama #10 โ
โ 763dcd6059324253 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 4mo ago
โ @Rama: If transport is not enabled, AP mode will have no effect. That setting only
โ affects code paths reachable when transport is enabled. So if it has an effect,
โ that's a pretty good sign that transport is actually enabled.
I meant that I added an AP mode interface onto my own remote transport node (on 1.2.5
now) and connected to it. That shut off the announces. Otherwise I'm still getting quite
a few every second if I connect to the gateway interface instead.
But those are nevertheless confounding variables, so I'll take all of this back and run
some more tests.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
[ 1 ] Next >
Page 1 of 2
โ INFO โ Identify to this node to post. How?
bottom